home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000543_connolly@pixel.convex.com _Tue Jan 12 05:21:44 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  15KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA19869; Tue, 12 Jan 93 05:21:44 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA28757; Tue, 12 Jan 1993 05:36:50 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA01091; Mon, 11 Jan 93 22:36:45 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA00126; Mon, 11 Jan 93 22:36:43 -0600
  10. Message-Id: <9301120436.AA00126@pixel.convex.com>
  11. To: www-talk@nxoc01.cern.ch
  12. Subject: HTML todo list
  13. Date: Mon, 11 Jan 93 22:36:43 CST
  14. From: Dan Connolly <connolly@pixel.convex.com>
  15.  
  16. Please excuse the bitching and moaning from the last message.
  17. My motto is "Accept the situation or do something about it."
  18. Kind of a condensed version of the serenity prayer.
  19.  
  20. Since I don't have resources to fix the whole HTML situation,
  21. here's a laundry list of everything I can think of about
  22. HTML. Perhaps discussions and code fixes can refer
  23. to "#15 in the HTML todo list" for example.
  24.  
  25.  
  26. In http://info.cern.ch/hypertext/WWW/Technical.html
  27.  
  28. 1. My dictionary lists "markup" as a word, not mark-up.
  29.   HTML format[4]          A description of the mark-up language used for some
  30.                          documents and for search hit-lists.
  31.  
  32. In http://info.cern.ch/hypertext/WWW/Daemon/Bugs.html
  33. 2. The PLAINTEXT situation should be logged as a bug against
  34. the server. PLAINTEXT is deprecated.
  35.  
  36. In http://info.cern.ch/hypertext/WWW/FAQ/List.html
  37. 4. HTML should support QUESTION and RESPONSE elements to
  38. support converting USENET FAQ's to HTML
  39.  
  40. In http://info.cern.ch/hypertext/WWW/Provider/ShellScript.html
  41. 5. PLAINTEXT is deprecated. Use PRE, and use a sed script
  42. to change < to <, > to >, and & to &.
  43.  
  44. 6. http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/dir2html.txt
  45. This thing doesn't quote attributes; it uses XMP in stead of
  46. PRE with numeric character references.
  47.  
  48. 7. http://info.cern.ch/hypertext/WWW/Tools/HTMLGeneration/ls2html.awk.txt
  49. Quotes around HREFS, PLAINTEXT.
  50.  
  51. 8. http://info.cern.ch/hypertext/WWW/Daemon/Implementation/asis.txt
  52. Quote HREFS, numeric character references where necessary.
  53.  
  54. 9. http://info.cern.ch/hypertext/WWW/HytelnetGate/src/htn2html.c
  55. Uses HEADER in stead of HEAD.
  56. Quote HREFs.
  57. Special character entities?
  58. Yeah! It uses numeric character references already!
  59.  
  60. In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
  61. 10. Mark-up again
  62.  
  63. 11. This text seems out of place:
  64. WWW parsers should
  65. ignore tags which they do not understand,
  66. and ignore attributes which they
  67. do not understand of tags which they
  68. do understand.
  69.  
  70. 12. Default text: this node seems to confuse lots of issues. I suggest
  71. we get rid of it. The way to look at HTML is as a stream of data and
  72. markup. Newlines are handled differently all over the place. It might
  73. be reasonable to talk about how newlines are handled by the text
  74. formatter, after they have been handed over from the SGML parser.
  75.  
  76. In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html
  77. 13. This text is out of place: 
  78. Each tag starts
  79. with a tag opener (a less than sign)
  80. and ends with a tag closer (a greater
  81. than sign).   Many tags have corresponding
  82. closing tags which identical except
  83. for a slash after the tag opener.
  84.  
  85. It's more thoroughly discussed in
  86. http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html
  87. [which still needs revision: it's correct, but could use better
  88. organization.]
  89.  
  90. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/HEAD.html
  91. 14. These blurbs should probably quote their element declarations
  92. from the DTD, in order to help folks learn to read the DTD.
  93. "Only certain elements are allowed" is vague: there are restrictions
  94. about the order and occurence sometimes too.
  95.  
  96. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/TITLE.html
  97. 15. This seems redundant:
  98. The title of a document is given
  99. between title tags:
  100. <pre>        <TITLE> ... </TITLE>
  101. </pre>
  102. Lexical details should be discussed elsewhere. The example is
  103. good, but the mention of tags is out of place.
  104.  
  105. 16. What does this mean?
  106. It should
  107. [...]
  108. ideally fit on one line.
  109.  
  110. 17. Should the TITLE element be CDATA, RCDATA, or PCDATA?
  111. If we want to be able to use Latin chars in the title,
  112. it can't be CDATA. The only difference between RCDATA
  113. and PCDATA (with no subelements allowed) is that comments
  114. are recognized in PCDATA, whereas they are just regular
  115. data in RCDATA.
  116.  
  117. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/ISINDEX.html
  118. 18. The word "Format" connotes lexical details, which are discussed
  119. elsewhere. I endorse the use of examples, but I'd like to keep
  120. the model of
  121.     SGML source ==parser==> ESIS ==WWW semantics==>formatted output
  122. consistent. The WWW semantics processor doesn't deal with <>'s etc.
  123. It just sees the presence of the ISINDEX element and acts accordingly.
  124.  
  125. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/NEXTID.html
  126. 19. The status of each element should be noted consistently. e.g.
  127. Mainstream    Consistently used by past, present, and future implementations.
  128. Deprecated    In use and will be supported, but should be avoided. (XMP)
  129. Obsolete    In use in some documents, but will not be supported. (NEXTID)
  130. Proposed    Not yet in the DTD or widely supported (e.g. LINK)
  131. Standard    Not yet widely supported, but will be (e.g. PRE)
  132. Extra        It's legal to ignore these. (e.g. EM)
  133.  
  134. http://info.cern.ch/hypertext/WWW/MarkUp/Elements/LINK.html
  135. 20. How many of these are allowed? I could change
  136. <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID?)>
  137. to
  138. <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK?)>
  139. or
  140. <!ELEMENT HEAD - -  (TITLE? & ISINDEX? & NEXTID? & LINK*)>
  141. I don't know if the latter is legal SGML. I'd have to try
  142. it out.
  143.  
  144. 21. Link types are not well defined. The only reason to put
  145. something in a public specification is so everybody can agree
  146. on some semantics. If there are no semantics to agree on,
  147. why include the TYPE attribute? (It's status is at best
  148. "proposed" in my mind, though it's in the DTD.)
  149.  
  150. In http://info.cern.ch/hypertext/WWW/MarkUp/Headings.html
  151. 22. "(at least six)" -- how about exactly six? Though I've
  152. seen a lot of style guides that frown on anything more than 4.
  153.  
  154. In http://info.cern.ch/hypertext/WWW/MarkUp/SGML.html
  155. 23. We should give at least one complete reference to the standard, i.e.
  156.  
  157.     ISO 8879:1986, Information Processing -- Text and
  158.         Office Systems -- Standard Generalized Markup Language
  159.                          (SGML)
  160.  
  161. 24. In the Archive section, we could metion comp.text.sgml,
  162. the SGMLs parser materials, and the ifi.uio.no archive.
  163.  
  164. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/A.html
  165. 25. All attribute values have to be quoted, including NAME.
  166. The example is wrong.
  167.  
  168. 26. The TYPE attribute hardly seems worth mentioning. In the DTD,
  169. it's a NAME, not just any old string.
  170.  
  171. 27. We should look at modeling anchors as HyTime linkends
  172. and/or ilinks.
  173.  
  174. 28. We should look at modeling the LINK element as a HyTime
  175. construct as well.
  176.  
  177. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/P.html
  178. 29. I don't like the use of "exact representation" here:
  179. The exact representation of
  180. this (indentation,  leading, etc)
  181. is not defined here, and may be a
  182. function of other tags, style sheets
  183. etc.
  184.  
  185. A reader could be confused between the source representation
  186. and the rendered format. The source representation certainly
  187. is defined. I'd say the "rendered representation" or some such.
  188.  
  189. 30. Where are P's allowed? In the DTD, they're allowed in:
  190. HTML, BODY, ADDRESS, BLOCKQUOTE, PRE but not in HEAD, A,
  191. CODE, SAMP, etc.
  192.  
  193. In http://info.cern.ch/hypertext/WWW/MarkUp/Lists.html
  194. 31. Ordered lists: Obsolete or Standard?
  195.  
  196. 32. "The format is:" Here again, this is an example, but it's
  197. hardly a specification of the format of a UL element.
  198.  
  199. 33. What does this mean?
  200. The opening list tag  must be immediately
  201. followed by the first list element.
  202.  
  203. 34. The important difference between UL, MENU, and DIR is not
  204. how they are displayed, but their semantic meanings. A MENU
  205. is a list of things to choose from. A DIR is a list of names
  206. in a directory.
  207.  
  208. 35. We could also make this semantic distinction between PRE,
  209. XMP, and LISTING, were it not for the syntactic confusion
  210. surrounding XMP and LISTING.
  211.  
  212. 36. Get rid of this:
  213. the closing tag must obviously match
  214. the opening tag.
  215.  
  216. In http://info.cern.ch/hypertext/WWW/MarkUp/Elements/PRE.html
  217. 37. Wording of the newline documentation:
  218. Line boundaries within the text are
  219. significant, except for one immediately
  220. following or immediatly preceding
  221. a tag.
  222.  
  223. I don't like saying "newlines are significant" or "not significant."
  224. Something like "newline characters shall be rendered as line breaks..."
  225. or "newlines shall be ignored by the renderer..." would be better.
  226.  
  227. 38. Semantics of newlines in PRE. Given the current DTD, a newline
  228. after the PRE start tag or before the PRE end tag is not reported
  229. by an SGML parser.
  230.  
  231. I think I can cook up some magic SHORTREF declarations that will
  232. cause the SGML parser to report the newlines (possibly as P tags).
  233. [This would obviate the need for special newline processing code
  234. in libHTML]
  235.  
  236. In any case, I'd suggest that ALL NEWLINES REPORTED BY THE SGML
  237. PARSER IN THE PRE ELEMENT BE DISPLAYED AS LINE BREAKS. That only
  238. leaves the issue of which newlines are reported, which is governed
  239. by the SGML standard.
  240.  
  241. 39. I don't like the way this is worded:
  242. The <p> tag should not be used.
  243. If found, it should be interpreted
  244. as a single new line.
  245.  
  246. I'd suggest: "it should be displayed as a line break" to avoid treating
  247. <P> as "\n" and interpreting "\n" in some strange way.
  248.  
  249. 40. "... character character highlighing elements may be used."
  250. Ack! I don't recommend this! Hmmm... maybe only the B, I, and U
  251. elements. This certainly conflicts with the current DTD.
  252.  
  253. In http://info.cern.ch/hypertext/WWW/MarkUp/Highlighting.html
  254. 41. These have status "Extra"
  255. Where not supported by implementations,
  256. like all tags, these should be ignored.<p>
  257.  
  258. This should be a warning to providers that some information may
  259. be lost on some browsers.
  260.  
  261. 42. (Definition of these and reference
  262. - Dan?)
  263. They come from TeXinfo.
  264.  
  265. 43. I left the TeXinfo @file element out. I don't remember why.
  266. It might have been an oversight. Do we want it in there?
  267.  
  268. 44. Examples (TBD) see complete.html in my stuff.
  269.  
  270. In http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html#z41
  271. 45. The PLAINTEXT tag terminates the HTML entity. What
  272. follows is not SGML. In stead, there's an HTTP convention
  273. that what follows is a text/plain body.
  274.  
  275. 46. "The text may contain any ISO Latin printable characters" --
  276. this conflicts with the DTD. I think a design that treats Latin
  277. characters as external data entities is cleaner than one that
  278. treats them as text characters, but I'm willing to go the
  279. other way.
  280.  
  281. 47. "including the
  282. tag opener, so long as it does not
  283. contain the closing tag in full."
  284. For Pete's sake, could we get this out of there once and for all?
  285. Perhaps it deserves a historical note or something, but we can't
  286. leave it in as part of the standard. I'm willing to support
  287. unquoted attribute values, but not this.
  288.  
  289. 48. "The <a  NAME="z22">XMP tag</a>..." Use the term "element". The
  290. term "tag" doesn't include the content of the element.
  291.  
  292. In http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
  293. 49. "Special characters are represented
  294. by SGML entities"
  295. They're represented by numeric character references.
  296. The lt, gt, and amp entities are not in the DTD. They should
  297. be supported for historical reasons, but they are obsolete.
  298.  
  299. In http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/HTML.html
  300. 50. I'd like to move the Abstract, Specification, and the reference to
  301. "Text and Markup" up into
  302. http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
  303. That node would look like
  304.  
  305. <H1>HyperText Markup Language</H1>
  306. <H3>Abstract</H3>...
  307. <H2>Language Reference</H2>
  308.     <A>Text and Markup</A>
  309.     <A>The Elements</A>
  310.     <A>Implementors' Guide</A>
  311. <H2>Specification</H2>
  312.     <A>the DTD</A>
  313. <H2>Appendices</H2>
  314.     <A>futures</A>
  315.     <A>constraints</A>
  316.  
  317. and this node would become "Implementors' Guide", with
  318. pointers to recommended, complete, tolerated, errors,
  319. libHTML, and SGMLs.
  320.  
  321. In http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/html.dtd
  322. 51. include ISO Latin 1 character set in SGML declaration?
  323.  
  324. 52. Put PLAINTEXT back in HTML element (fell out by mistake.)
  325.  
  326. 53. LINK element?
  327.  
  328. 54. Get rid of H5 and H6?
  329.  
  330. 55. Get rid of link TYPE lement?
  331.  
  332. 56. Document BLOCKQUOTE in Elements reference.
  333.  
  334. 57. EXPIRES attribute on HEAD?
  335.  
  336. 58. Get rid of NEXTID element?
  337.  
  338. 59. Document URN, TITLE, METHODS attributes of A element.
  339.  
  340. 60. Proposed Headers element (like a DL; for RFC822 message headers:
  341. <HEADERS>
  342. <dt>To<dd>connolly@convex.com
  343. <dt>Subject<dd>HTML todo list
  344. </HEADERS>)
  345.  
  346. 61. List STYLE attribute?
  347.  
  348. 62. XMP and LISTING: CDATA or RCDATA?
  349.  
  350. In http://info.cern.ch/hypertext/WWW/MarkUp/Connolly/Current/Text.html
  351. 63. Under "Parsing Content Into Data and Markup," improve the
  352. explanation of the MIXED, ELEMENT, EMPTY, CDATA, and RCDATA content
  353. types (PCDATA is the wrong term) and how it affects parsing.
  354.  
  355. 64. Revise the section on the sample implementation, libHTML, and
  356. supported.html.
  357.  
  358. In http://info.cern.ch/hypertext/WWW/Test/test.html
  359. 65. This node should be moved to the implementos' guide.
  360.  
  361. In http://info.cern.ch/hypertext/WWW/MarkUp/Future.html
  362. 66. Delete the reference to the perl script.
  363.  
  364. 67. There are two references here to old versions of my spec.
  365.  
  366. 68. Header: it's in there: HEAD
  367.  
  368. 69. Highlighting: it's in there (get rid of HP1 etc. in Elements reference)
  369.  
  370. 70. Fixed width with anchors: it's in there: PRE.
  371.  
  372. 71. Entities: Latin chars are in there. What do we need bullets for?
  373.  
  374. 72. Comments: the comment element is a bad idea. SGML comments are
  375. documented and supported.
  376.  
  377. 73. Link types: we should look at HyTime before we go much further
  378. on this.
  379.  
  380.  
  381. In the midaswww-1.0 browser: [by the way: I've fixed all these in my copy]
  382.  
  383. 74. HREF's with quotes don't work
  384.  
  385. 75. Unrecognized tags are treated as data, rather than ignored.
  386.  
  387. 76. numeric character references and entity references aren't supported.
  388.  
  389. 77. ETAGO doesn't end XMP, LISTING, PLAINTEXT unless it's the right
  390. GI. (e.g. <XMP>foo</foo> blah : blah should not be in the XMP element.)
  391.  
  392. 78. local: acess scheme is wierd. I suggest we go with ftp: and
  393. local-file: to match MIME, and get rid of local: and file:
  394.  
  395.  
  396. Well, that's all I can think of. Good night.
  397.  
  398. Dan